Method and apparatus for use in a communications network

ABSTRACT

A method and apparatus for use in a communications network in which a Mobile Node accesses the communications network via a proxy node. The proxy node is arranged to handle mobility signalling on behalf of the Mobile Node. At a mobility anchor function, such as a Local Mobility Anchor, a first Care-of-Address associated with the Mobile Node is registered. When the mobility anchor function receives a registration request to register a second Care-of-Address associated with the Mobile Node, it sends a request message to the proxy node acting on behalf of the Mobile Node. The request message instructs the proxy node to check whether the Mobile Node is reachable using the first Care-of-Address.

TECHNICAL FIELD

The present invention relates to communications networks, and inparticular to a method for use in a Proxy Mobile IP communicationsnetwork.

BACKGROUND

Mobile IPv6 (MIPv6), which is described in IETF RFC 3775, allows usersof mobile communications devices to move from one network to anotherwhilst maintaining a permanent IP address, regardless of which networkthey are in. This allows the user to maintain connections whilst on themove. For example, if a user were participating in a Voice Over IP(VoIP) session and, during the session the user moved from one networkto another, without MIPv6 support the user's IP address may change. Thiswould lead to problems with the VoIP session.

A Mobile Node (MN) is allocated two IP addresses: a permanent homeaddress and a care-of address (CoA). The CoA is associated with anaccess network, an IP subnet, that the user is currently visiting. Tocommunicate with the MN, packets are sent to the MN home address. Thesepackets are intercepted by a Home Agent (HA) in the home network, whichhas knowledge of the current CoA. The Home Agent then tunnels thepackets to the CoA of the MN with a new IP header, whilst preserving theoriginal IP header. When the packets are received by the MN, it removesthe new IP header and obtains the original IP header. The MN sendspackets to another node by tunnelling them to the HA, encapsulated inpackets addressed to the HA. For each packet, the HA removes theencapsulating packet, restores the original packet and forwards it tothe intended destination node.

Proxy Mobile IPv6 (PMIPv6), IETF draft-sgundave-mip6-proxymip6-02,describes a Mobile Access Gateway (MAG) function. This function emulateshome link properties in order to make a MN behave as though it is on itshome network and allows support for mobility on networks that would nototherwise support MIPv6. A key difference between PMIPv6 and MIPv6 isthat using MIPv6, a MN has control of its own mobility signalling,whereas using PMIPv6, a MN does not have control of its mobilitysignalling. The basic components of a PMIPv6 architecture areillustrated in FIG. 1.

A MAG 101 is usually implemented at the access router. The MAG 101 sendsand receives mobility related signalling on behalf of a MN 102. When aMN 102 connects to an access router having a MAG 101, the MN 102presents its identity in the form of a Network Access Identifier (NAI)as part of an access authentication procedure. Once the MN 102 has beenauthenticated, the MAG obtains the user's profile from a policy store.The MAG 101, having knowledge of the user profile and the NAI, can nowemulate the MN's home network. The MN 102 subsequently obtains its homeaddress from the MAG. The MAG 101 also informs the MN's 102 LocalMobility Anchor (LMA) 103 of the current location of the MN 102 using aProxy Binding Update message. The Proxy Binding Update message uses theNAI of the MN 102. Upon receipt of the Proxy Binding Update message, theLMA 103 sets up a tunnel to the MAG 101 and sends a Proxy BindingAcknowledgement to the MAG. On receipt of the Proxy BindingAcknowledgement, the MAG 101 sets up a tunnel to the LMA, effectivelyforming a bidirectional tunnel. All traffic to and from the MN 102 isrouted through the LMA 103 via the bidirectional tunnel. A MAG may servemany MNs associated with the same LMA. The MAG and the LMA do not needto have a dedicated bidirectional tunnel for each MN. Instead the samebidirectional tunnel can be used for the traffic of all the MNs that areassociated with the same LMA and that are currently being served by thesame MAG.

The LMA 103 intercepts any packet that is sent to the MN 102, andforwards the intercepted packet to the MAG 101 through the tunnel. Onreceipt of the packet, the MAG 101 removes the tunnel header and sendsthe packet to the MN 102. The MAG 101 acts as a default router on theaccess link. Any packets sent from the MN are sent via the MAG 101through the tunnel to the LMA 103, which then sends the packet on to itsultimate destination.

Simultaneous Multi-Access describes a function of a communicationsnetwork that allows a MN to combine different radio and/or fixed accesstechnologies, as illustrated in FIG. 2. The MN 102 can simultaneouslyuse several interfaces and different access networks (AN1 and AN2),which may employ different access technologies, in a communicationssession. Different traffic flows, belonging to different applicationscan be transferred between different access networks, independently ofeach other.

MIPv6 can be extended to support Simultaneous Multi-Access (see R.Wakikawa et al., “Multiple Care-of Addresses Registration”,Internet-Draft draft-ietf-monami6-multiplecoa-02, March 2007). Wheremore than one access is used, a MN has a CoA for each access. A BindingUnique Identifier (BID) is associated with each CoA, and the BIDindicates which CoA a Binding Update (BU) relates to. If the BIDassociated with a new CoA is already in use, the new CoA replaces theone previously associated with the BID, whereas if the BID is notalready in use, the new CoA is added to any previously existing CoAs.Since MIPv6 is host-centric (that is to say, the MN is in control of itsmobility signalling), with all the mobility signalling flowing betweenthe MN and the HA, the MN has a complete overview and complete controlof how CoAs are added to or replacing each other, by assigning the BIDsappropriately.

Using PMIPv6, the MN is not in control of its mobility signalling. Asdescribed above, mobility signalling is handled by a MAG on behalf ofthe MN. A Proxy Binding Update (PBU) is triggered when the MN attachesto an access and the MAG responsible for the access. This means that aMN has no way of indicating its intentions regarding how the accessesare to be used in terms of PMIPv6, i.e. whether a new access should beadded to the already used accesses or replace one or more old one(s).

In the absence of explicit intention indications from the MN, the PMIPv6LMA can operate in either of two modes:

1. Simultaneous Multi-Access mode, where new CoAs are added to old onesand an old CoA is deregistered only when the MN detaches (explicitly orimplicitly by losing contact) from the corresponding access.

2. Non-simultaneous multi-access mode, where only a single CoA is usedat a time and a new CoA consequently replaces the previous one.

Although the description of the Simultaneous Multi-Access mode aboveclearly states that a new CoA should always be added to the existingones and never replaces an old one, a problem can arise when a MNattaches to a new access and the MAG of that access registers a new CoAin the LMA. In accordance with the simultaneous multi-access mode theLMA will not deregister the old CoA(s). However, the reason forattaching to the new access might well have been that the MN lost an old(and possibly only) access. If this is the case, the MN has notexplicitly signalled to the old access that it has detached (even ifsuch means were available in the old access network) and the MAG of theold access has to rely on some kind of time-out or periodic checkmechanism, e.g. neighbour unreachability detection (NUD), to detect thedetachment before it deregisters the CoA in the LMA. Before thedetachment is detected and the old CoA deregistered, the LMA maycontinue to send traffic to the old MAG, and so packets in that trafficare lost when forwarded to the no longer attached MN. It would bedesirable to prevent this packet loss.

SUMMARY

When a LMA (operating in simultaneous multi-access mode) receives aregistration of a new CoA, it sends a message to the MAG of each of theold accesses (for which CoAs are still registered) and asks therespective MAG to immediately explicitly check whether the MN is stillreachable through the access. Each MAG carries out the requested check,preferably using an ICMPv6 Echo Request message, and deregisters the CoAin the LMA if the MN is not reachable.

According to a first aspect of the invention, there is provided a methodfor use in a communications network in which a Mobile Node accesses thecommunications network via a proxy node. The proxy node is arranged tohandle mobility signalling on behalf of the Mobile Node. At a mobilityanchor function, which is typically a Local Mobility Anchor, a firstCare-of-Address associated with the Mobile Node is registered. When themobility anchor function receives a registration request to register asecond Care-of-Address associated with the Mobile Node, it sends arequest message to the proxy node acting on behalf of the Mobile Node.The request message instructs the proxy node to check whether the MobileNode is reachable using the first Care-of-Address. In this way, themobility anchor function can be informed as to whether theCare-of-Address is still in use by the Mobile Node.

The communications network is optionally selected from one of a ProxyMobile IPv4 network and a Proxy Mobile IPv6 network, the mobility anchorfunction is a Local Mobility Anchor function, and the proxy node is aMobile Access Gateway.

Optionally, the method further comprises receiving a response messagefrom the proxy node, the response message being triggered by the requestmessage. The response message can be used to inform the mobility anchorfunction whether or not the Care-of-Address is still in use by theMobile Node. Alternatively, if no response is received from the proxynode, then the mobility anchor function takes no further action, and thefirst Care-of-Address remains registered at the mobility anchorfunction.

Optionally, the response message requests the mobility anchor functionto deregister the first Care-of-Address. The response message optionallyincludes information informing the Local Mobility Anchor function thatthe Mobile Node can not be reached using the first Care-of-Address, inwhich case the mobility anchor function can take action to deregisterthe first Care-of-Address. This allows the mobility anchor function topositively know that the Mobile Node is no longer reachable using thefirst Care-of-Address. In a further alternative, the response messageincludes information informing the mobility anchor function that theMobile Node can be reached using the first Care-of-Address, in whichcase the mobility anchor function need take no further action. Again,this allows the mobility anchor function to positively know that theMobile Node is reachable using the first Care-of-Address.

The method optionally comprises sending the request message to aplurality of proxy nodes, each proxy node associated with aCare-of-Address, each Care-of-Address associated with the Mobile Node.This is a typical situation of a mobility anchor function such as aLocal Mobility Anchor serving several proxy nodes, or MAGs, and allowsthe mobility anchor function to maintain track of differentCare-of-Addresses that may be used ny the Mobile Node operating in aSimultaneous Multi-access mode, even where different proxy nodes areserving the Mobile Node for different accesses.

The request message is optionally selected from a Proxy Mobile IPv6message and a Proxy Mobile IPv4 Register Revocation message, the ProxyMobile IPv4 Register Revocation message comprising a flag indicatingthat revocation of the Care-of-Address is conditional upon the MobileNode being unreachable.

The proxy node, after receiving the request message from the mobilityanchor function, optionally determines the reachability status of theMobile Node. An example of a way to determine the reachability status ofthe Mobile Node is to send query message to the Mobile Node. The querymessage is optionally selected from one of an Internet Control MessageProtocol for IPv4 Echo Request message, an Internet Control MessageProtocol for IPv6 Echo Request message, a Neighbour Solicitation messageand an Address Resolution Protocol message. By determining thereachability of the Mobile Node using the Care-of-Address, the proxynode can inform the mobility anchor function of the reachability of theMobile Node. As described above, the proxy node can positively informthe mobility anchor function of the reachability of the Mobile Node, orcan make no response, in which case the mobility anchor function assumesthat the Mobile Node is reachable using the first Care-of-Address.

The method optionally further comprises, after receiving theregistration request to register a second Care-of-Address associatedwith the Mobile Node, caching copies of all incoming packets directed tothe first Care-of-Address. In the event that the Mobile Node isunreachable using the first Care-of-Address, the cached packets are sentto the second Care-of-Address. The cache is then cleared and furthercaching is stopped for all incoming packets directed to the firstCare-of-Address. In this way, packet loss in the event that a MobileNode is unreachable using the first Care-of-Address is minimized.

Optionally, the method comprises, after receiving the registrationrequest to register a second Care-of-Address associated with the MobileNode, caching copies of all incoming packets directed to the firstCare-of-Address. In the event that the mobility anchor function receivesa message from the proxy node indicating that the Mobile Node isreachable using the first Care-of-Address, the cache is cleared and nofurther copies of incoming packets directed to the first Care-of-Addressare cached. This prevents unnecessary caching of packets once it hasbeen determined that the Mobile Node is reachable using the firstCare-of-Address.

According to a second aspect of the invention, there is provided amobility anchor node for use in a communications network in which aMobile Node accesses the communications network via a proxy node. Themobility anchor node comprises means for registering a firstCare-of-Address associated with a Mobile Node, a receiver for receivinga registration request to register a second Care-of-Address associatedwith the Mobile Node, and a transmitter for transmitting a requestmessage to the proxy node, the request message instructing the proxynode to determine whether the Mobile Node is reachable using the firstCare-of-Address.

The mobility anchor node optionally comprises means for receiving aresponse message from the proxy node, the response message being sent inresponse to the request message, and means for de-registering the firstCare-of-Address at the mobility anchor function.

The transmitter is optionally arranged to transmit the request messageto a plurality of proxy nodes, each proxy node associated with aCare-of-Address, each Care-of-Address associated with the Mobile Node.This is because a mobility anchor node typically serves several proxynodes.

To avoid unnecessary packet loss, the mobility anchor node optionallycomprises means for caching copies of all incoming packets directed tothe first Care-of-Address, and means for, in the event that the MobileNode is unreachable using the first Care-of-Address, sending the cachedpackets to the second Care-of-Address and clearing the cache.

According to a third aspect of the invention, there is provided a proxynode for use in a communications network in which a Mobile Node accessesthe communications network via a proxy node. The proxy node comprises areceiver for receiving a request message sent from a mobility anchornode, the request message related to the reachability of a Mobile Nodeattached to the proxy node using a Care-of-Address. The proxy nodefurther comprises a transmitter for sending a query to the Mobile Node,and means for determining whether the Mobile Node is reachable using theCare-of-Address. Means for sending a message to the mobility anchor nodeare provided, the message comprising information selected frominformation informing the mobility anchor node that the Mobile Node isunreachable using the first Care-of-Address, and information requestingthe mobility anchor function to deregister the first Care-of-Address.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically in a block diagram a Proxy Mobile IPv6architecture;

FIG. 2 illustrates schematically in a block diagram a SimultaneousMulti-Access architecture;

FIG. 3 is a flow diagram illustrating the steps of an embodiment of theinvention; and

FIG. 4 illustrates schematically in a block diagram a node for useaccording to embodiments of the invention.

DETAILED DESCRIPTION

The following description sets forth specific details, such asparticular embodiments, procedures, techniques, etc. for purposes ofexplanation and not limitation. It will be appreciated by one skilled inthe art that other embodiments may be employed apart from these specificdetails. In some instances, detailed descriptions of well known methods,interfaces, circuits, and devices are omitted so as not obscure thedescription with unnecessary detail. Moreover, individual blocks areshown in some of the figures. Those skilled in the art will appreciatethat the functions of those blocks may be implemented using individualhardware circuits, using software programs and data, in conjunction witha suitably programmed digital microprocessor or general purposecomputer, using application specific integrated circuitry (ASIC), and/orusing one or more digital signal processors (DSPs).

FIG. 3 herein illustrates the method of an embodiment of the invention.Using the numbering of FIG. 3, the steps are as follows:

301. When a Mobile Node (MN) attached to a PMIPv6 supporting network isoperating in a Simultaneous Multi-Access mode, it will have severalCare-of-Addresses (CoA) registered with a Local Mobility Anchor. EachCoA may be used to reach the MN via a Mobile Access Gateway (MAG).

302. When the MN performs a further network attachment to another MAG,the MAG sends a request to the LMA to register a further CoA to be usedfor the further session.

303. The further CoA is registered at the LMA. However, in case one ofthe already registered CoAs is no longer valid, it is desirable to checkwhether the MN has simply added a new access to a set of simultaneousaccesses or has attached to the new access in order to replace an oldone that it has lost or for some other reason is no longer using.

304. The LMA sends a reachability check request message (typically aPMIPv6 message is used, but if the network is a PMIPv4 network, thereachability check request is sent in a PMIPv4 message, e.g. indicatedby a new flag in an existing PMIPv4 Register Revocation message, therebymaking the revocation conditional (i.e. executed only if the terminal isunreachable) to each MAG that is associated with a registered CoA otherthan the latest CoA registered in the previous step. The reachabilitycheck request message instructs the MAG to immediately explicitly checkwhether the MN is still reachable. Note that in FIG. 3, a check forreachability using two CoAs from two associated MAGs is shown, but asillustrated by the dashed arrow, this check is performed by every MAGthat has a registered CoA associated with it (other than the latest CoAregistered in the previous step).

305. Each MAG checks the MN's reachability on the CoA that the MAG hasregistered in the LMA on behalf of the MN. The check may or may not beaccess specific. Typically the MAG sends a query message to the MN. Thequery message may be access specific. In many accesses a neighboursolicitation message (or ARP request in IPv4 networks) is used, oralternatively an ICMPv6 (or ICMPv4) Echo Request message is used.

306. If the MN is still reachable on the concerned CoA, e.g. if the MAGreceives a response from the MN using a specific CoA then no furtheraction is taken.

307. If, on the other hand, the MAG determines that the MN is no longerreachable, e.g. because it receives no response from the MN, then itrequests the LMA to deregister the relevant CoA.

308. The LMA then deregisters each CoA on which the MN has beendetermined unreachable, e.g. for which no response from the MN has beenreceived. In this way, a CoA is not maintained as registered ifconnectivity has been lost or the MN is no longer using that CoA for anyreason.

It will be appreciated that specific steps of the method may vary. Forexample, the flow diagram shows no further action being taken if a MAGdetermines that a MN is reachable, e.g. if it receives a response fromthe MN. However, the MAG may report this positive result to the LMA toensure that the LMA is aware that the CoA is still in use and shouldmaintain its registered state. This alternative procedure would servethe purpose of making the protocol more robust.

Referring to FIG. 4, there is illustrated a node for use in a PMIPv6network. In the case where the node is a LMA, the LMA comprises storagemeans 401 for storing a registration of all CoAs associated with a MN.The LMA further comprises a receiver for receiving signalling, such asthe request to register a further CoA, and the results of thereachability of the MN using different CoAs. A processor 403 is alsoprovided for updating the storage means 401 by registering the furtherCoA and deregistering any registered CoAs which are no longer valid. Atransmitter 404 is also provided, that is used to send messages to MAGsto instruct them to perform a reachability check.

In the case where the node illustrated in FIG. 4 is a MAG, the MAGcomprises a receiver 402′ for receiving a reachability check instructionmessage from the LMA. The MAG further comprises a processor 403′ forconstructing a query message, and a transmitter 404′ for sending thequery message to the MN. A further receiver, which may or may not be thesame receiver as 402′, is also used for receiving a response to thequery from the MN, and a further transmitter, which may or may not bethe same transmitter as 404′, is also used for sending the results ofthe MN query to the LMA. Typically, the MAG will communicate with theLMA and the MN through different interfaces, and so it is most likelythat different physical transmitters and receivers are provided.

The invention significantly reduces the time an LMA maintains aregistration for a CoA that is no longer in use, thereby reducing thenumber of packets lost where a CoA is no longer reachable. However, somepackets may still be sent towards this CoA, and thus lost, before theLMA deregisters an invalid CoA. To avoid this packet loss, according toa further embodiment the LMA caches copies of the packets sent towards aCoA with uncertain status when it sends the request to the correspondingMAG.

If it transpires that the CoA is reachable (and that its correspondingaccess can therefore be used), the LMA stops caching packet copies anddiscards the already cached packet copies. If on the other hand ittranspires that a CoA with uncertain status is not reachable, then theLMA may send the cached packet copies towards the newly registered CoA(or to any other CoA that is shown to be reachable).

In the case where packets are cached, the MAG returns an explicitresponse to the LMA's reachability check request, even if the CoAassociated with the MAG is reachable, so that the LMA knows when to stopcaching packet copies. The response message may be in the form of a newPMIPv6 message or as a flag in an existing message. If the PMIPv4 (seeK. Leung et al., “Mobility Management using Proxy Mobile IPv4”,Internet-Draft draft-leung-mip4-proxy-mode-02, January 2007) is used,the Registration Revocation Acknowledgement message can be used for theresponse, e.g. by including a new flag or status code.]

The invention provides a fast way to determine whether a new CoA isbeing registered to replace an old CoA or whether it should simply beadded to an existing set of CoAs for PMIPv6 in simultaneous multi-accessmode. The risk of forwarding packets to an invalid CoA is reduced forPMIPv6 in simultaneous multi-access mode, and with the optional systemof caching copies of packets in the LMA, packet losses can be avoided inthe time it takes for the LMA to ascertain the status of a given CoA.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiments withoutdeparting from the scope of the present invention. For example, whilstthe invention is described using the examples of Proxy MIP or PMIPv6, itwill be appreciated that it may also be used for any protocol thatsupports gateways or proxy gateways.

The following acronyms have been used in this specification:

ARP Address Resolution Protocol

BID Binding Unique Identifier

BU Binding Update

CoA Care-of Address

HA Home Agent

ICMPv4 Internet Control Message Protocol for IPv4

ICMPv6 Internet Control Message Protocol for IPv6

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

LMA Local Mobility Anchor

MAG Mobile Access Gateway

MIPv6 Mobile IPv6

MN Mobile Node

NUD Neighbor Unreachability Detection

PBU Proxy Binding Update

PMIPv6 Proxy Mobile IPv6

PMIPv4 Proxy Mobile IPv4

RFC Request For Comments

1. A method for use in a communications network in which a Mobile Nodeaccesses the communications network via a proxy node, the proxy nodearranged to handle mobility signalling on behalf of the Mobile Node, themethod comprising: at a mobility anchor function, registering a firstCare-of-Address associated with the Mobile Node receiving a registrationrequest to register a second Care-of-Address associated with the MobileNode; and sending a request message to the proxy node acting on behalfof the Mobile Node, the request message instructing the proxy node tocheck whether the Mobile Node is reachable using the firstCare-of-Address.
 2. The method according to claim 1, wherein thecommunications network is selected from one of a Proxy Mobile IPv4network and a Proxy Mobile IPv6 network, the mobility anchor function isa Local Mobility Anchor function, and the proxy node is a Mobile AccessGateway.
 3. The method according to claim 1 or 2, further comprisingreceiving a response message from the proxy node, the response messagebeing triggered by the request message.
 4. The method according to claim3, wherein the response message requests the mobility anchor function toderegister the first Care-of-Address.
 5. The method according to claim3, wherein the response message includes information informing themobility anchor function that the Mobile Node can not be reached usingthe first Care-of-Address.
 6. The method according to claim 3, whereinthe response message includes information informing the mobility anchorfunction that the Mobile Node can be reached using the firstCare-of-Address.
 7. The method according to any one of the precedingclaims, comprising: sending the request message to a plurality of proxynodes, each proxy node associated with a Care-of-Address, eachCare-of-Address associated with the Mobile Node;
 8. The method accordingto any one of the preceding claims, wherein the request message isselected from a Proxy Mobile IPv6 message and a Proxy Mobile IPv4Register Revocation message, the Proxy Mobile IPv4 Register Revocationmessage comprising a flag indicating that revocation of theCare-of-Address is conditional upon the Mobile Node being unreachable.9. The method according to any one of the preceding claims, furthercomprising, at the proxy node, after receiving the request message fromthe mobility anchor function, determining the reachability status of theMobile Node.
 10. The method according to claim 9, wherein thedetermining the reachability status of the Mobile Node comprises sendinga query message to the Mobile Node.
 11. The method according to claim10, wherein the query message is selected from one of an InternetControl Message Protocol for IPv4 Echo Request message, an InternetControl Message Protocol for IPv6 Echo Request message, a NeighbourSolicitation message and an Address resolution Protocol message.
 12. Themethod according to any one of the preceding claims, further comprising:after receiving the registration request to register a secondCare-of-Address associated with the Mobile Node, at the mobility anchorfunction, caching copies of all incoming packets directed to the firstCare-of-Address; and in the event that the Mobile Node is unreachableusing the first Care-of-Address, sending the cached packets to thesecond Care-of-Address, clearing the cache and stopping caching copiesof all incoming packets directed to the first Care-of-Address.
 13. Themethod according to any one of claims 1 to 11, further comprising: afterreceiving the registration request to register a second Care-of-Addressassociated with the Mobile Node, at the mobility anchor function,caching copies of all incoming packets directed to the firstCare-of-Address; at the mobility anchor function, receiving a messagefrom the proxy node indicating that the Mobile Node is reachable usingthe first Care-of-Address; and clearing the cache and stopping cachingcopies of incoming packets directed to the first Care-of-Address.
 14. Amobility anchor node for use in a communications network in which aMobile Node accesses the communications network via a proxy node, themobility anchor node comprising: means for registering a firstCare-of-Address associated with a Mobile Node a receiver for receiving aregistration request to register a second Care-of-Address associatedwith the Mobile Node; and a transmitter for transmitting a requestmessage to the proxy node, the request message instructing the proxynode to determine whether the Mobile Node is reachable using the firstCare-of-Address.
 15. The mobility anchor node according to claim 14,further comprising: means for receiving a response message from theproxy node, the response message being triggered by the request message;and means for de-registering the first Care-of-Address at the mobilityanchor function.
 16. The mobility anchor node according to claim 14 or15, wherein the transmitter is arranged to transmit the request messageto a plurality of proxy nodes, each proxy node associated with aCare-of-Address, each Care-of-Address associated with the Mobile Node.17. The mobility anchor node according to claim 14, 15 or 16, furthercomprising: means for caching copies of all incoming packets directed tothe first Care-of-Address; and means for, in the event that the MobileNode is unreachable using the first Care-of-Address, sending the cachedpackets to the second Care-of-Address and clearing the cache.
 18. Aproxy node for use in a communications network in which a Mobile Nodeaccesses the communications network via a proxy node, the nodecomprising: a receiver for receiving a request message sent from amobility anchor node, the request message related to the reachability ofa Mobile Node attached to the proxy node using a Care-of-Address; atransmitter for sending a query to the Mobile Node; and means fordetermining whether the Mobile Node is reachable using theCare-of-Address; and means for sending a message to the mobility anchornode, the message comprising information selected from informationinforming the mobility anchor node that the Mobile Node is unreachableusing the first Care-of-Address, information informing the mobilityanchor node that the Mobile Node is reachable using the firstCare-of-Address, and information requesting the mobility anchor functionto deregister the first Care-of-Address.